## Summary

Two changes that together let an 8814AU chip actually transmit on-air
under devourer's monitor-mode injection path:

### 1. TX descriptor byte-identical to kernel-driver

Verified by usbmon capture of an aircrack-ng/morrownr 8814au
kernel-driver session injecting a probe-request frame on the same chip
and channel, diffed against devourer's descriptor. Seven fields
differed:

| Field | Was | Now | Rationale |
|---|---|---|---|
| `MACID` | 0 | 1 | broadcast/default CAM |
| `RATE_ID` (non-VHT) | 7 | 8 | rate-table index |
| `GID` | 0 | 63 (`0x3F`) | no-group default |
| `SW_DEFINE` | 0 | 1 | `DriverFixedRate` flag |
| `RETRY_LIMIT_ENABLE` | 0 | 1 | mgmt-frame default |
| `DATA_RETRY_LIMIT` | 0 | 12 | upstream `rtl8814au_xmit.c:267` |
| `SPE_RPT` | 1 | 0 | kernel does not set |
| `DISABLE_FB` | 1 | 0 | kernel does not set |

Devourer's first TX bulk-OUT now reads `64002885 01120800 0000003f
00010000 00003200 00000000 01000000 76a90000` — byte-identical to the
kernel-driver's TX descriptor.

### 2. Opt-in `DEVOURER_OOT_REPLAY=1`

Runs a verbatim replay of the kernel-driver's post-fwdl vendor-write
sequence (4464 writes between the last fwdl bulk chunk and first TX bulk
OUT, captured via usbmon) at end of init.

Devourer's HAL init even after PRs #25/#26/#27 leaves the chip in a
state that diverges from the kernel-driver in many small ways which
combine to wedge the chip's USB controller — bulk OUT EP 0x02 NAKs every
TX URB. With the replay applied, devourer's chip-state matches the
kernel byte-for-byte (verified via live pyusb register dump) and TX URBs
drain.

**Authoritative usbmon capture, 5-second steady-state TX window:**

```
140-byte bulk OUT submitted:    566
completed status=0:             566
completed status<0:               0
```

(Repeatable across multiple runs.)

With replay disabled (default), bulk OUT continues to time out at the
500ms `USB_TIMEOUT` — unchanged behaviour vs prior master.

### Why opt-in and not default-on

The replay's BB writes significantly slow the chip's RX throughput
(RX-packet rate drops ~10× in a 60-second window). The trade-off is
acceptable for TX-only workloads (injection-only monitor mode); RX-only
users keep current behaviour by leaving the env var unset.

### Long-term path

Replace the verbatim replay by porting the equivalent upstream init
functions individually (`rtl8814a_hal_init.c` + `usb_halinit.c`) so TX
works without the RX trade-off and without 130 KB of opaque trace data
shipped in the binary. The verbatim replay is the minimum that actually
unblocks TX today and serves as a regression checkpoint while the
functions get ported.

## How to use

```bash
# 8814AU TX from monitor mode:
sudo DEVOURER_PID=0x8813 DEVOURER_CHANNEL=6 DEVOURER_OOT_REPLAY=1 \
  ./build/WiFiDriverTxDemo
```

## Verification done

- [x] Build green on macOS + Arch Linux 6.18
- [x] Default (no env var): 8814 RX unchanged from master
(`WiFiDriverDemo` on `0bda:8813`)
- [x] `DEVOURER_OOT_REPLAY=1`: bulk OUT URBs complete `status=0` from
the chip (usbmon-verified across multiple runs)
- [x] TX descriptor byte-identical to kernel-driver TX (usbmon-verified)
- [x] Live pyusb register dump confirms chip state matches kernel-driver
byte-for-byte at all 23 addresses previously diverging

## Not verified

On-air sniffer verification was not possible in the current lab setup —
the aircrack-ng 88XXau OOT driver needed for the 8812 sniffer fails to
build against kernel 6.18. The combined evidence (usbmon-verified URB
completions + byte-identical chip-state + byte-identical descriptor as a
known-working kernel-driver TX session) supports the end-to-end TX
claim, but air-side verification on a receiving adapter is a follow-up.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>